Original text info on entities by Niklata (Nicholas Dwarkanath) - nichd@norfolk.infi.net
Additions and HTMLization by Thomas Winzig - thomas.winzig@webcom.com
You can get the most up-to-date version of the Quake Entity Specs (http://www.infi.net/~nichd/qentity.html) from Niklata's Technical Resources (http://www.infi.net/~nichd/).
This is the text version of the Quake Entities specs. It is not updated as frequently as the HTML version and it certainly does not look as good. You may not distribute the text version of the Quake Entities list without first packaging the HTML version in the same archive as the text version is being distributed in. Reason: This version looks bad and is more difficult to read/navigate than the HTML version. This version is here solely for those without HTML viewers/web browsers.
**WARNING - BADLY FORMATTED TEXT ALERT - AUTO-CONVERTED FROM HTML**
Here's a good list of entities and their properties. This should help you
in making editors/building MAP files. If you find an error, or figure something out
that I don't know, please email Niklata. I'll put your contribution and you'll get your name in here as well.
When I give you frameworks for a structure, the individual entries can be in any order, and lots are optional. I try to mark if an
entry is optional. Lots of stuff here may be optional, I just haven't tested it yet to know. I'll clean
up this list later once I do some testing, so don't worry.
In a "" block, your choices for that block are delimited by commas.
I'll get to describing the "spawnflags" tag in a bit - it controls stuff
like difficulty levels, etc. It won't take me long to do... I'll have it finished
soon.
Table of Contents
Section 1: Intro
1.1: What's New
1.2: Contributors
Section 2: General entity/.map information
2.1: .map Header (entity #0)
2.2: "spawnflags" tag
2.3: Optional parameters for triggers
2.4: General entity syntax
2.5: General entity list
Section 3: Entity 'class' examples
3.1: Lights
3.2: Player movement tags
3.3: Movers (Doors, plats, etc)
3.4: Triggers/Switches
3.5: Traps/Things harmful to you
3.6: Misc./Stuff I have no idea about
Section 4: Special Entity-related structures
4.1: Moving platforms
Section 1: Intro
1.1 What's new:
More organized, table of contents, contributors list, fixed some stuff. The "model" tag is something you don't have to worry about. This is just a reference that QBSP puts into the final BSP file, telling Quake
which brush the entity behavior attaches to. Everything that I used to give a "model" tag in here now tells you that it must attach to a brush. This means that it must be put inside the actual brush declaration statement. Ex:
{
"classname" "trigger_changelevel"
"map" "e1m1" // Map to change to on trigger
{
<INSERT BRUSH DATA HERE>
}
}
1.2 Contributors:
Thomas Winzig - Confirmation on the "model" tag's behavior. HTMLization of this doc.
Clarified several things. Reorganized the document structure a little bit.
Brian Hackert - Info on how to use func_train and path_corner. Told me that "targetname" and "target" can have real names for their argument, not just numbers.
Section 2: General entity/.map information
2.1 .map Header (entity #0):
"sounds" "#" // Tells the CD player which track to play.
"classname" "worldspawn" // Tells Quake to spawn the world
"wad" "DIRPATH" // tells what graphics (texture) WAD2 file to use.
"message" "TITLE" // The title of the level
"worldtype" "#" // Describes environment? 0, 1 (Ziggurat Vertigo's), 2 will work
2.2 "spawnflags" tag:
I believe that anything with an origin tag can have an optional 'spawnflags' tag. This is not confirmed, however. I'll be working
out the bits soon!
1 - Larger Health/Larger Ammo
2 - Megahealth
2.3 Optional parameters for triggers:
"message" "MESSAGETEXT" (use \n for linebreaks) - Displays message
on screen. Can be put in any trigger block - but will only work in some. For
example, Quake won't give an error if you put a "message" block in a monster's
declaration, but you won't see the message, either (AFAIK).
"wait" "#" // Waits # 10ths of a second. Can be put in any trigger block.
2.4 General Entity syntax:
In order to complement the Unofficial Quake Specs, rather than confuse, we will follow what those authors have described
as far as entities are concerned. Maybe this document will eventually be
added into the UQS?
John Wakelin (a partial author of UQS) says this about the entities in Quake:
The entities define the monsters, things, but also the positions in space
where something must happen. So they are the Quake equivalent of both the THINGS and the LINEDEF types from DOOM.
The entity definitions are made up of a series of specific details that
define what each is, where it starts, when it appears etc. Each specific is followed
by a modifier that arguments it. All definitions have the classname specific that identifies that entity. The classname specifics relate intimately with the code lump and are the names of functions written in QuakeC.
I have chosen the terms ``specific'' and ``arg'' for the two different parts
of each detail of the definition. These terms may or may not suit but, they
will have to do until we learn what id calls them.
Line feeds (ASCII 0x0a) separate each definition and each line in the definition. Spaces (ASCII 0x20) separate specifics from args. I tried changing them around and it does not seem to matter what separates them as long as
it is white space.
I should add that you can also use C++ style comments in map files, as we
do throughout the entity descriptions. Here are the known 'specifics' and
'args' in Quake shareware (mainly reproduced from the UQS):
Now you define each of the path_corners it will travel to. When it reaches
a path_corner, it will float to the next path_corner defined in the "trigger"
tag of the path_corner. The platform will start at the path_corner pointed
to by the platform's "trigger" tag. It will continue the loop indefinitely
and it will go through walls to get to its destination. Here's its path_corners
would look like:
{
"classname" "path_corner"
"origin" "0 0 0"
"targetname" "t1dest1"
"target"" "t1dest2"
}
{
"classname" "path_corner"
"origin" "0 128 0"
"targetname" "t1dest2"
"target"" "t1dest1"
}
4.2 Monsters and Triggers:
Have you been wondering how you can get events to trigger when a monster dies, as first
seen in E1M2 with the demons? Well, it's not too difficult. When you attach a
trigger tag to a monster, the monster's death will trigger the event. I believe
(not tested) that if other monsters have a triggername tag the same as a monster
with the trigger tag, the trigger event will only occur when all monsters with
a matching triggername tag are dead. The monster with the trigger tag need not
have the triggername tag.
Quake is Copyright 1996 id Software. Some information about entities was obtained from the Unofficial Quake Specs, a truly awesome reference guide to Quake editing (although a little outdated in some respects).
Disclaimer: This document is provided as is and may not be perfect. I do not guarentee the validity of any of the information in it. I will not be held liable or responsible for any damages caused from use or misuse of the information contained within this document.
